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Method, System and Agent for Third Generation Partnership Project 
(3GPP) Technical Specification (TS) Document Number Exchange 

PRIORITY UNDER 35 ILS.C. S 119(e) & 37 CFR S 1.78 

This nonprovisional patent application claims priority based upon the prior 
U.S provisional patent application entitled "Method of IRP Versioning", 
application number 60/293,802, filed on 05/25/2001, in the names of Andre 
Godin, Nicolas Gosselin, David McAleer and Edwin Tse. 

BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates generally to the field of communications 
15 networks and, more specifically, to standard identification communications 
between telecommunications nodes. 

Description of the Related Art 

A communications network typically comprises a plurality of 
2 0 communications nodes, which "speak" to each other by exchanging various 
classes of messages, representing commands, data, requests, replies, notifications 
or others, according to the technology and protocol used within each such 
network. For meaningful communications to take place between communications 
nodes, the message syntax and semantics must be understood and agreed among 
25 the communicating nodes. The document that specifies the syntax and semantics 
of the messages exchanged between nodes is sometimes called the interface 
specification, technical specification or protocol. At the operation level, the 
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Integration Reference Point (IRP) is one of such protocols, through which the 
communications messages are exchanged between nodes in a management 
system. There are many types of IRP specifications or protocols, such as for 
example for fault management (Alarm IRP) and for configuration management 
5 (Basic Configuration IRP). 

In 3 rd Generation Partnership Project (3GPP) based communications 
environments, the IRP specifications define and control network management- 
related communications between an Element Management - Network 
Management node (EM-NM) and the controlled Network Elements nodes (NEs). 

10 Various IRP specifications exist for defining communications in a 

plurality of network management sub-fields. In the fault/alarm management field, 
one of the most basic needs is to support alarm surveillance. Product specific 
applications use the Alarm IRP specification to be able to forward alarm 
notifications from various NEs and to a Fault Monitoring (FM) application. 

15 Another IRP specification is the Basic Configuration Management IRP 
specification that defines and controls the management of topology and logical 
resources in the managed network (retrieval of the configuration and status of the 
network elements). Finally, the Performance Monitoring (PM) is achieved 
according to the Performance Data IRP specification. 

2 0 Reference is now made to Fig. l.a (Prior Art), which shows a nodal 

operation and signal flow diagram of a typical prior art scenario for exchanging 
IRP specification names between two communications nodes. In Fig. l.a, a 
management system 100 comprises an IRP Manager 102 that communicates with 
an IRP Agent 104. For this purpose, the Manager 102 must first know the 

25 supported IRP specification and version used and supported by the IRP Agent 
104. Each type of IRP specification defines a mandatory method called 
getXXXIRPVersionQ, wherein "XXX" refers to the given type of IRP 
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specification. For example, the method getAlarmIRPVersion() is used for 
deducting the Alarm IRP specification supported by a given node. With reference 
to Fig. La (Prior Art), prior to any further communications, the IRP Manager 102 
transmits a getXXXIRPVersion request message 106 to Agent 104 for inquiring 
5 of the Agent's supported IRP specification version, to which the Agent 104 
replies with a getXXXIRPVersion reply message 108 comprising a parameter 1 10 
indicative of a list of elements, each containing the name and the version number 
the Agent's supported IRP specifications. In current implementation, an element 
of the parameter 1 10 consists of three characters, such as for example "If 1". 

10 Reference is now made to Fig. l.b (Prior Art), which shown a schematic 

representation of the structure of one element 120 of the parameter 110 returned 
in the message 108 shown in Fig. La. The element 120 consists of three segments 
122, 124 and 126, wherein the first segment 122 refers to the IRP IS version 
number (which represent the version number of the IRP Information Service), the 

15 second segment 124 refers to the type of IRP specification type, and the third 
segment refers to the IRP SS version number (which represent the version number 
of the IRP Solution Set). For example, the string "If 1" means that the Agent 104 
(shown in Fig. La) implements the IRP IS version number 1 of the ("f Fault) 
Alarm IRP specification, IRP SS version number L 

2 o There are three problems with the above way of handling and transmitting 

the IRP specification name and version. The first problem is that the IRP 
specifications evolve through the acceptance by the standard body of multiple 
technical specification Change Requests (CRs) made by industry players. CRs 
writers do not always take into account if their proposed changes affect the IRP 

2 5 version number or not. CR writers typically do not suggest to change the constant 
strings representing the notification categories in the NotificationlRPConstDefs 
IDL file, an Interface Description Language (IDL). Referring to Fig La, the 
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notification categories are represented by the parameter 110 comprised in 
message 108. If the constant strings representing the notification categories are 
not adequately changed in the NotificationlRPConstDefs IDL file (not shown in 
Fig. La; information from the IDL file defines the IRP type and version number, 
5 and is compiled by the Agent for the generation of the appropriate parameter 110) 
as and when required by CRs, which oftentimes occurs nowadays, IRP Manager 
102 may be given the erroneous IRP version supported by the Agent 104. 

The second problem is the lack of clear understanding of the standard 
body members on how to handle multiple CRs, where some CRs affect backward 

10 compatibility while others do not. By not considering that some CRs affect 
backward compatibility or by processing CRs in the wrong order, the process may 
end-up by having wrong values for constant strings representing the notification 
categories, such as the values sent in parameter 1 10 of Fig. La. 

Finally, the third problem is that whenever a version number of any IRP 

15 specification is changed, it also requires a new version number for the given 
Notification IRP specification, since all the constant strings representing the 
notification categories are defined in a NotificationlRPConstDefs IDL file, which 
is included in a Notification IRP SS document. Consistent reviews of all IRP 
specifications impacted by an accepted CR are not always performed by the 

20 standard body, which sometimes creates transmission confusion and errors 
between interconnected nodes implementing signalling based upon the given IRP 
specification. 

Accordingly, it should be readily appreciated that in order to overcome the 
deficiencies and shortcomings of the existing solutions, it would be advantageous 
2 5 to have a scheme that unequivocally identifies a technical specification (protocol) 
used by co-operating nodes. The present invention provides such a solution. 
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SUMMARY OF THE INVENTION 

In one aspect, the present invention is a method for transmitting an 
indication of a communications protocol supported by a first communications 
5 node, the method comprising the steps of: 

i) transmitting from a second communications node to the first 
communications node a request for a protocol supported by the first 
communications node; and 

ii) responsive to the request, transmitting a reply message comprising a 

JlT 10 parameter indicative of a Third Generation Partnership Project (3GPP) Technical 

O 

3 Specification (TS) document number defining at least a protocol supported by the 

\- first communications node. 

ry In another aspect, the present invention is a management system 

£ comprising: 

J* , 15 a second node; 

111 a first node receiving from the second communications node a request for 

3 s :: lj 

I u 

y ! a protocol supported by the first communications node; 

H wherein responsive to the request, the first node transmits to the second 

node a reply message comprising a parameter indicative of a Third Generation 
2 0 Partnership Project (3 GPP) Technical Specification (TS) document number 
defining at least a protocol supported by the first communications node. 

In yet another aspect, the present invention is an agent receiving from a 
manager a request for a protocol supported by the Agent, and responsive to the 
request, transmitting a reply message comprising a parameter indicative of a Third 
2 5 Generation Partnership Project (3GPP) Technical Specification (TS) document 
number defining at least a protocol supported by the agent. 
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Brief Description of the Drawings 

For a more detailed understanding of the invention, for further objects and 
advantages thereof, reference can now be made to the following description, taken 
in conjunction with the accompanying drawings, in which: 

Figure l.a (Prior Art) is a nodal operation and signal flow diagram of a 
typical prior art scenario for exchanging Integration Reference Point (IRP) 
specification names and versions between two communications nodes; 

Figure Lb (Prior Art) is a schematic representation of the structure of an 
element of the getXXXIRPVersion reply message used in a typical prior art 
scenario for exchanging IRP specification names and versions between two 
communications nodes; 

Figure 2.a is a nodal operation and signal flow diagram illustrative of the 
preferred embodiment of the present invention related to the use of the Third 
Generation Partnership Project (3GPP) document number in communications 
between cooperating nodes in a network management system; and 

Figure 2.b is an exemplary flowchart diagram illustrative of the set-up of 
an exemplary abridged technical specification version number computed 
according to the preferred embodiment of the present invention. 

Detailed Description of the Preferred Embodiments 

The innovative teachings of the present invention will be described with 
particular reference to numerous exemplary embodiments. However, it should be 
2 5 understood that this class of embodiments provides only a few examples of the 
many advantageous uses of the innovative teachings of the invention. In general, 
statements made in the specification of the present application do not necessarily 
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limit any of the various claimed aspects of the present invention. Moreover, some 
statements may apply to some inventive features but not to others. In the 
drawings, like or similar elements are designated with identical reference 
numerals throughout the several views, and the various elements depicted are not 
5 necessarily drawn to scale. 

The Third Generation Partnership Project (3GPP) assigns document 
numbers, such as for example the document number "3GPP TS 32.106-3 v3.2.0" 
jy. to each 3GPP technical specification it publishes. DDL files and GDMO (General 

Definition of Managed Objects) definitions, which represent the protocol 
fU 10 interface and the managed object model to support, are part of the 3GPP technical 

m specification having a unique document number. Therefore, the present invention 

proposes to use the 3GPP document number of each 3GPP technical specification 
in order to unambiguously identify the DDL files and GDMO definitions used by 
each node in communications between cooperating nodes of a communications 
15 network. 

Referring now to Fig. 2.a, depicted therein is a nodal operation and signal 
flow diagram illustrative of the preferred embodiment of the present invention 
related to the use of the 3GPP document number in communications between 
cooperating nodes in a network management system. The network management 
2 0 system 200 comprises an Agent 202 in communication with a Manager 204. Prior 
to exchanging any message, the Manager 204 must know the protocol used and 
supported by the Agent 202. For example, the Manager 204 may inquire of the 
supported technical specification (protocol) used by the cooperating Agent 202 
(the IDL definition it supports) by sending a GetXXXIRPVersion request 
25 message 210 to the Agent 202. Upon receipt of the request message 210, 
according to the preferred embodiment of the invention, the Agent computes 
(including retrieving from a memory) an abridged technical specification version 
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number that uniquely identifies the used protocol, action 212, and returns the 
abridged technical specification version number 214 to the Manager 204 in a 
GetXXXIRPVersion reply message 216. If the Agent 202 supports multiple 
versions of the alarm IRP:SS (the Alarm IRP Solution Set), then the Agent 
5 includes in the reply message 216a plurality of abridged version numbers, each of 
which identifies a specific version of 3GPP Alarm IRP:SS technical specification. 
In this manner, the Manager 204 is informed of all the Alarm IRP:SS technical 
specifications supported by the Agent 202. Based on this first exchange, Manager 
204 knows exactly which protocol to use to send requests to Agent 202. 
O io Reference is now made to Fig. 2.b, which shows an exemplary flowchart 

m diagram illustrative of a set-up of an exemplary abridged technical specification 

+! version number that may be computed in step 212 of Fig. 2.a. According to the 

y invention, the method starts at 300 with the full name of a 3GPP technical 

f specification, such as for example with "3GPP TS 32.106-3 v3.2.0" 302. At step 

M 15 304 the method discard the header of the technical specification name, and the 

rp ' 

m name is reduced to the string "32.106-3 v3.2.0" 306. At step 308, the method 

discards all characters after (and including) the last period, and the string name is 
further reduced to "32.106-3 v3.2" 310. Finally, at step 312, the method 
eliminates all white spaces from the remaining string and capitalizes the final 
20 string, that becomes the computed abridged technical specification version 
number "32. 106-3 V3.2" 214. 

Reference is now made back to Fig. 2.a, which further shows another use 
of the abridged technical specification version number according to the preferred 
embodiment of the invention. The Manager 204 transmits a 
25 GetNotificationCategory request message 220 for inquiring of the technical 
specification version of the alarm notifications sent by the Agent 202. The Agent 
202 receives the request 220, and computes the abridged technical specification 
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version number in the manner already described with relation to Fig. 2.b. Then the 
Agent 202 returns the abridged technical specification version number 214 to the 
Manager 204 in a GetNotificationCategory reply message 222. Following 
message 222, all the alarm notifications 224 and 226 sent by the Agent 202 to 
Manager 204 comprise the abridged technical specification version number 214 in 
their header so that Manager 204 knows exactly the format of the notification it 
receives from Agent 202. 

Fig. 2.a further shows yet another use of the abridged technical 
specification version number according to the preferred embodiment of the 
invention. The Manager 204 may transmit a GetNetworkResourceSchemalD 
request message 240 for inquiring of the set of Managed Object Classes (e.g. 
Generic NRM, UTRAN NRM) of the network resource schema identification. 
The set of Managed Object Classes of the network resource schema identification 
defines all the Managed Object classes and their attributes. The Agent 202 
computes the technical specification version number of the supported technical 
specification, as previously described with relation to Fig. 2.a. For example, if the 
Agent 202 supports one particular version of the Generic NRM and one particular 
version of the UTRAN (UMTS Terrestrial Radio Access Network) NRM, the 
getNetworkResourceSchemaldQ reply message 242 to the 
getNetworkResourceSchemaldQ request message 240 may contain two abridged 
version numbers 214\ and 214 2 , each of which identifies a specific 3GPP 
specification. If the Agent 202 supports two particular versions, one of which is 
backward compatible to the other, of the Generic NRM, the 
getNetworkResourceSchemaId() reply message 242 also contains two abridged 
version numbers, each of which identifies a specific supported version of the 
3GPP specification. 
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Based upon the foregoing, it should now be apparent to those of ordinary 
skill in the art that the present invention provides an advantageous solution, which 
offers unambiguous identification of the appropriate technical specification 
(protocol) used by cooperating nodes. Therefore, the invention simplifies the 
handling of the standard change request process, eliminates the need to update 
constant strings in IDL file(s), and allows for unambiguous identification of the 
protocol used by cooperating nodes. It should be realized upon reference hereto 
that the innovative teachings contained herein are not necessarily limited to the 
disclosed examples. For example, although the invention has been described with 
reference to communications between an agent and a manager of a management 
system, it is understood that the invention is also applicable to any kind of 
networks and network nodes. It is believed that the operation and construction of 
the present invention will be apparent from the foregoing description. While the 
method and system shown and described have been characterized as being 
preferred, it will be readily apparent that various changes and modifications could 
be made therein without departing from the scope of the invention as defined by 
the claims set forth hereinbelow. 

Although several preferred embodiments of the method and system of the 
present invention have been illustrated in the accompanying Drawings and 
described in the foregoing Detailed Description, it will be understood that the 
invention is not limited to the embodiments disclosed, but is capable of numerous 
rearrangements, modifications and substitutions without departing from the spirit 
of the invention as set forth and defined by the following claims. 
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